FIG. 1 of the accompanying drawings illustrates schematically a mobile network architecture including a General Packet Radio Service (GPRS) access network and an IP Multimedia Subsystem (IMS). The IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP multimedia services over mobile communication networks. IP multimedia services can provide a dynamic combination of voice, video, messaging, data, etc. within the same session. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals. The Session Description Protocol (SDP), carried by SIP signals, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, the IMS allows operators and service providers to control user access to services and to charge users accordingly.
As shown in FIG. 1, managing of communications of user terminals (user equipment, UE; not shown in the figure) that connect to the network of FIG. 1 can be considered as held at three layers (or planes). The lowest layer (illustrated in FIG. 1 as “Connectivity Layer 1”), is also referred to as the bearer or user plane, and provides the connectivity means through which signals are directed to/from UEs accessing the network. The entities within the connectivity layer 1 that connect a UE to a further network providing application services (e.g. allowing an IMS subscriber to access from his UE to IMS services provided by IMS service network 3b) form a network that is referred to as an IP-Connectivity Access Network, IP-CAN. A GPRS network is an example of an IP-CAN network and, apart of the radio access nodes, includes various GPRS Support Nodes (GSNs), such as Gateway GPRS Support Nodes (GGSN) and Serving GPRS Support Nodes (SGSN). A GGSN (e.g. GGSN 2a) cooperates with one or more SGSNs, and acts as an interface between the GPRS backbone network and other networks (such as an IMS network). A middle layer (illustrated in FIG. 1 as “Control Layer 4”) implements control functions relating to the signals held by the IP-CAN network. For example, in case of an IP-CAN network comprising GPRS, part of these functions can be implemented by SGSNs and GGSNs of the IP-CAN network, and relate to the processing of signals received from, or addressing to, a UE that connects through the IP-CAN network (e.g. bearer establishment, bearer termination, etc). At the top of a UE's communication there can be further servers managing high-layer aspects of the communication (illustrated in FIG. 1 by an “Application Layer 6” comprising one or more “Application Servers 7”).
In the illustrated example, the IMS subsystem 3 includes a core network 3a and a service network 3b. The IMS core network 3a includes nodes that send/receive signals to/from nodes in the IP-CAN network (e.g. via the GGSN 2a). In particular, the IMS 3 comprises network nodes (known as “Call Session Control Functions, CSCFs, which operate as SIP proxies, and which are arranged to communicate with nodes of an IP-CAN network that perform connectivity and control functions (e.g. with a GGSN 2a).
The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the user that the user is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF. Application Servers (AS) 7 can be provided for implementing some of IMS service functionality. For example, an AS 7 can receive and process signaling related to a UE (i.e. as received from an IP-CAN network to which the UE attaches) so as to control higher layer aspects of a service (e.g. divert an incoming call to a voice mail service, or forward it to a certain terminal, etc).
A Home Subscriber Server (HSS) 9, or User Profile Server Function (UPSF), is a user database that supports the IMS network entities that handle calls. The HSS 9 contains subscription-related information (such as subscriber profiles), performs authentication and authorization of a subscriber, and provides information about the subscriber's location and IP information. The HSS 9 is similar to the GSM Home Location Register (HLR) and Authentication Centre (AuC).
Currently the Sh interface (see 3GPP TS 29.328 and 29.329) provides mechanisms for subscriptions to notifications concerning user data changes. As illustrated in the message exchange diagram of FIG. 2 of the accompanying drawings, this mechanism allows an Application Server 7 to be notified about changes, creation or removal of specified user data in the HSS 9 using the Sh-Subs-Notif (Subscribe-Notifications-Request or SNR) command (FIG. 2; message 1). The HSS 9 may accept the subscription and possibly return the current value of the data subscribed in the Sh-Subs-Notif-Response (Subscribe-Notifications-Answer or SNA; message 2 of FIG. 2).
When the subscription is accepted, whenever the requested user data (e.g. location data) changes, the HSS 9 notifies the AS 7 about this change by sending a Sh-Notif (Push-Notification-Request or PNR) command with the new value (e.g. new S-CSCF name, new MSC/VLR number).
The present applicant has identified the following technical limitations with the currently-defined behaviour over the Sh interface, which will be explained with reference to the message exchange diagram of FIG. 3 of the accompanying drawings. The example illustrated by FIG. 3 relates to a scenario where an operator wishes to send “welcome” greetings and local information when a user powers on their equipment, based on the location of the user. In this case, the service logic needs to be notified when the status is changed to “registered”, and to be able to know the type of message to be sent to the user (e.g. local tourist attractions), the location data is also needed.
When the service logic for a certain user in the AS 7 needs to be informed when certain data (data-reference) changes its value, the AS 7 sends a Sh-Subs-Notif (SNR) command for each and every data requested (e.g. registration status, location data, service data, etc.). This can be done with multiple SNR commands each with a single data-reference, or a single SNR command including multiple data-reference values. The latter approach is illustrated by messages 1 and 2 of FIG. 3 (subscribing to changes in user status and location).
Regardless of the procedure used, the HSS 9 will send a notification (PNR) to the AS 7 every time the data changes. If multiple data are requested, as in the example of FIG. 3, this will result in multiple (and separate) notifications, no matter what the new value is, no matter what the old value was and no matter what the current value of other data-reference is. This is illustrated by messages 3 to 6 of FIG. 3 (the two instances of messages 3 and 4 relate to two separate respective changes in location data for the user, while message 5 and 6 relate to a change in the status of the user).
The present applicant has come to the significant appreciation that there is presently no possibility of performing some criteria/filtering over the Sh interface. Hence, the AS 7 may receive notifications that are ignored because they are not needed by the service logic. Taking into account the amount of users and the number of data-references, the impact on the Sh signalling may be big, especially when using TCP/SCTP connections (as it happens for Diameter protocol used by Sh), which demands also CPU capacity (to control the sequence numbers, for example).
In addition, the present applicant has appreciated that the current mechanism forces the AS 7 to subscribe to several data-reference items unnecessarily; e.g. an AS 7 may need to be informed about a change in registration status, and only when this data changes does it also need the location data to execute the service logic (which does not necessarily mean that the location data changes on its own are needed). This scenario requires that the AS 7 subscribes to both data (and eventually receiving notifications that are discarded; e.g. when the location data is changed without a user status change), or that the AS 7 subscribes only to location data, and when the notification is received, the AS 7 needs to read the current value of location data using Sh-Pull (UDR). In both cases, there is a lot of extra signalling over the interface. In addition, in most cases it requires that the AS 7 cannot work in a data-less configuration, since the data needs to be stored/cached for future use. This data is then stored both in the HSS 9 and temporarily in the AS 7, which does not allow a cluster of ASs 7 to execute the service logic in a load balancing configuration.
It is desirable to address the above issue as identified and formulated by the present applicant.